📖 11.1 비공개 메서드와 테스트 취약성
🔖 11.1.1 비공개 메서드와 테스트 취약성
비공개 메서드를 노출하면 테스트가 구현 세부사항과 결합되고 결과적으로 리팩터링 내성이 떨어진다.
- 비공개 메서드를 직접 테스트하는 대신, 포괄적인 식별할 수 있는 동작으로서 간접적으로 테스트하는 것이 좋다.
🔖 11.1.2 비공개 메서드와 불필요한 커버리지
때로는 비공개 메서드가 너무 복잡해서 식별할 수 있는 동작으로 테스트하기에 충분히 커버리지를 얻을 수 없는 경우가 있다. 만약, 식별할 수 있는 동작에 합리적인 테스트 커버리지가 있다면 다음과 같은 문제가 발생할 수 있다.
- 죽은 코드
- 추상화 누락
🔖 11.1.3 비공개 메서드 테스트가 타당한 경우
비공개 메서드를 테스트하는 것 자체는 나쁘지 않다. 비공개 메서드가 구현 세부 사항의 프록시에 해당하므로 나쁜 것이다.
📖 11.2 비공개 상태 노출
단위 테스트 목적으로만 비공개 상태를 노출하는 안티 패턴이 있다.
- 테스트는 제품 코드와 정확히 같은 방식으로 SUT와 상호 작용해야 함
- 테스트 유의성을 위해 공개 API 노출 영역을 넓히는 것은 좋지 않은 관습
📖 11.3 테스트로 유출된 도메인 지식
도메인 지식을 테스트로 유출하는 것은 또 하나의 흔한 안티 패턴이다.
- 리팩터링 내성이 최악이다.
- 단위 테스트에서는 예상 결과를 하드코딩하는 것이 좋다.
📖 11.4 코드 오염
코드 오염은 테스트에만 필요한 제품 코드를 추가하는 것
- 테스트 코드와 제품 코드가 혼재돼 유지비가 증가
- 테스트 코드를 제품 코드베이스와 분리해야 한다.
📖 11.5 구체 클래스를 목으로 처리하기
구체 클래스를 대신 목으로 처리해서 본래 클래스의 기능 일부를 보존할 수 있으며, 이는 때때로 유용할 수 있다.
- 그러나 단일 책임 원칙을 위배할 수도 잇다.
- 즉, 일부 기능을 지키려고 구체 클래스를 목으로 처리해야 하면, 이는 단일 책임 원칙을 위반하는 결과다.
📖 11.6 시간 처리하기
실행 단계의 시간이 검증 단계의 시간과 다를 수 있다. 이 의존성을 안정화 하는 데는 세 가지 방법이 있다.
🔖 11.6.1 앰비언트 컨텍스트로서의 시간
앰비언트 컨텍스트로 사용하는 것은 안티 패턴이다.
- 제품 코드를 오염
- 테스트를 더 어렵게 한다.
- 정적 필드는 테스트 간에 공유하는 의존성을 도입해 해당 테스트를 통합 테스트 영역으로 전환
🔖 11.6.2 명시적 의존성으로서의 시간
서비스 또는 일반 값으로 시간 의존성을 명시적으로 주입하는 것
- 서비스로 주입하는 것보다는 값으로 주입하는 것이 더 낫다.
- 제품 코드에서 일반 값으로 작업하는 것이 더 쉽다.
- 테스트에서 해당 값을 스텁으로 처리하기도 더 쉽다.
- 비즈니스 연산을 시작할 때는 서비스로 시간을 주입한 다음, 나머지 연산에서 값으로 전달하는 것이 좋다.
